-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Support renaming viewmodel classes in migrations #182
base: master
Are you sure you want to change the base?
Conversation
This means we can swap names by skipping version ranges
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, small number of comments.
Co-authored-by: Andrew Childs <andrew.childs@bibo.com.ph>
To identify a migrated schema version for caching purposes, we need to use both the current and target schema versions. Otherwise if we were to make future migrations that would affect the result when migrating to older views (e.g. by discarding and reconstructing data), the cache would not be invalidated and cached results would be different from computed ones.
So there are two issues that are blocking this: 1: registering the historical names and versions in the registry at A possible solution to this would be to split the deferral in two, to resolve the class name and the historical versions independently. Then, 2: View aliases. Presently, alias names aren't registered at old versions at all, which is simply insufficient. But also, if a view has aliases, we don't know when they're valid from. We might have to extend the Alternatively, the alias names only exist for the MTI subclassing, which we don't like and wish we didn't have any more. If we were to implement #165, we could go ahead and release https://github.com/iknow/eikaiwa_content/pull/1598 which would remove the need for aliases, and we could drop that feature entirely. |
Alternative approach to (1) that would require less careful maintenance of the deferred structures: Rather than the registry maintaining the full map of name -> version -> class, it could instead have
At construction time you need to make sure there is no version overlap. Then because not all the version resolution is done eagerly, the only “deferred” step has to be adding the main class name, and that only needs to be deferred until the class name actually exists. Alias names and historical names can be added immediately: at the time a view_alias call or a migrates { renamed_from: } is encountered. |
If a viewmodel class changes name, migrations become a lot harder: clients specifying the old name in their X-ViewModel-Versions will be ignored, old client views won't be migrated up, and new server views won't be migrated down. This can only be partially mitigated by doing the migration in a parent view: it would have to use the parent view version change as a proxy for the child view+name change.
Instead, provide first class support for declaring that a migration changes a view's name with
renamed_from :Foo